CISA’s Known Exploited Vulnerabilities catalog was never designed with a stamping press in mind. The remediation deadlines attached to KEV entries assume a patch cycle that looks like IT: you test in a lower environment, you push the update, you reboot, you move on. That model works fine for a fleet of laptops. It falls apart the moment the asset in question is a PLC running a firmware version the vendor stopped supporting years ago, sitting inline on a line that runs three shifts and only comes down twice a year for planned maintenance.
That gap isn’t hypothetical anymore. CISA has kept expanding the ICS-relevant slice of the KEV catalog, and federal directives plus a growing wave of state and insurance-driven requirements have pushed “remediate within a defined window” language further into critical infrastructure and manufacturing generally. Meanwhile the actual physics of the plant floor haven’t changed at all. You still can’t patch a Modicon or a SLC-500-era controller without a change window, a safety walkdown, and sign-off from operations. The result is a real and growing population of open KEV items sitting against assets nobody can touch until the next outage — sometimes months out.
The mismatch is structural, not a compliance failure
It’s worth saying plainly: an open KEV item against a PLC that can’t be patched until scheduled downtime is not, by itself, evidence of negligence. It’s evidence of an operational constraint that every serious OT security practitioner recognizes. The problem is that most plants don’t have a clean, defensible way to say that to an auditor, an insurer, or a post-incident review board. “We knew about it and we were waiting for the outage” is true and reasonable, but if it’s not documented as a formal risk decision with compensating controls attached, it reads — after the fact — exactly like negligence. The fix isn’t lobbying CISA to relax the clock. It’s building the paper trail and the technical controls that let you say “we accepted this risk deliberately, with mitigations, and here’s the evidence” instead of “we knew and did nothing.”
Triage against the Purdue model first, not the CVSS score
The instinct when a KEV alert lands is to look at CVSS severity and start counting days. That’s the wrong first filter for OT. The right first filter is where the asset sits in the Purdue architecture and what’s actually reachable from it.
- Level 0/1 devices with no routable path from Level 3 or above — genuinely isolated PLCs and RTUs behind a properly configured DMZ — carry materially lower real-world exploitability than the CVSS score alone suggests, because most KEV entries assume network reachability. Document that isolation explicitly; don’t assume the auditor knows your architecture.
- Devices with any bridge to Level 3/4 — engineering workstations with dual-homed NICs, remote access jump boxes, vendor VPN tunnels for remote support — deserve the urgency the KEV deadline implies, because the exploit path is real, not theoretical.
- Safety-related PLCs (SIS, ESD logic) get pulled into a different lane entirely — change control there is governed by IEC 61511 practice as much as by cybersecurity policy, and a rushed patch can itself become the safety incident.
This triage produces a ranked list where “unsupported firmware, internet-adjacent, no segmentation” sits at the top and “unsupported firmware, air-gapped, safety-rated, six-year track record with no anomalous traffic” sits much further down — even if both showed up in the same KEV bulletin.
Build the compensating-control stack before you need it
For anything that can’t be patched before its outage window, the compensating-control playbook needs to cover three layers, and it needs to be standing infrastructure, not something assembled during an audit scramble.
Network isolation. Firewall rules or a Layer 3 switch ACL that restrict traffic to the specific PLC to only the specific source IPs, ports, and protocols required for the process to run — nothing more. If the vendor’s advisory names a specific service or port exploited by the vulnerability, block it explicitly and log the block. Reference ISA-95 and ISA/IEC 62443 zone-and-conduit segmentation in the documentation; auditors recognize the framework and it gives your isolation decision a standard to point to rather than an ad hoc justification.
Virtual patching via IPS. An industrial-aware intrusion prevention system — whether that’s a purpose-built OT security appliance or a next-gen firewall with ICS protocol signatures — can often shield the specific exploit signature named in the KEV entry even though the underlying firmware stays vulnerable. This is the single most defensible technical control in this playbook because it maps directly to the specific CVE: you can show, signature by signature, that the exploitation technique CISA flagged is blocked at the network layer even though the device itself remains unpatched.
Enhanced monitoring. Baseline the PLC’s normal traffic pattern — polling intervals, source addresses, protocol behavior — and alert on deviation. Passive OT monitoring tools that fingerprint Modbus, DNP3, or EtherNet/IP traffic without touching the controller are the standard here precisely because they don’t require touching a device you’ve already decided not to touch.
Writing the exception so it survives scrutiny
The document that ties this together is a formal risk acceptance record, not an email thread. It should name the specific KEV entry and CVE, state plainly why immediate remediation isn’t operationally feasible, list the compensating controls in place with dates they were implemented, name who approved the exception and at what authority level, and set a hard review date tied to the next planned outage — not “as soon as possible.” Attach evidence: firewall rule exports, IPS signature confirmation, monitoring dashboard screenshots. Insurers underwriting cyber policies for manufacturing increasingly ask for exactly this kind of artifact during renewal, and a post-incident review team looks entirely differently at a documented, dated, approved exception than at silence.
The uncomfortable truth practitioners need to sit with is that this playbook doesn’t close the gap — it manages it. A firewall rule and an IPS signature are not the same as a patched controller, and you should never let the compensating-control stack become a permanent substitute for the outage. The point of the documentation is to prove the delay was a deliberate, informed, reviewed decision with real mitigations attached — not to make the delay disappear.
What to actually do this quarter
If you don’t already have a standing mapping between your KEV-relevant asset inventory and your Purdue zones, that’s the first gap to close — you can’t triage what you haven’t mapped. Second, get your IPS or OT monitoring vendor to confirm, in writing, which specific KEV entries their current signature set actually covers; “ICS-aware IPS” is not the same claim as “blocks CVE-2025-whatever.” Third, build the risk-acceptance template now, before the next advisory lands, so it’s a fifteen-minute fill-in-the-blanks exercise instead of a scramble. The plants that come out of this cycle looking competent aren’t the ones that never have an open KEV item against unsupported firmware — they’re the ones who can produce a dated, signed, evidenced explanation for every one they do.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
